Overview
Multiplexing allows multiple input event streams to be combined into a single output event stream such that any input event is immediately passed through to the output. Any events can be multiplexed together to form a compound, multiplexed event.
Why Multiplex Events?
There are two main reasons for multiplexing events:
- Multiple events can be grouped by multiplexing and then passed through a single pin across a circuit boundary before being demultiplexed at the other end. In the case where the same set of events are distributed many ways or passed across circuit boundaries through pins, it can be much easier to deal with them as a group.
- It may be desirable to have two events execute the same method. If the operations to be performed are completely independent for the two events then it usually makes more sense to have two separate methods dealing with each, but if they need to share state then multiplexing them into the same method is a convenient way of doing this without requiring arbitrated storage.
How Does CLIP Support Multiplexing?
CLIP provides a Multiplexer object that supports event multiplexing. The following example shows a multiplexer that consumes from three stores (StoreA, StoreB and StoreC) and provides its multiplexed event to a method, MethodX. As soon as any of the store events are generated, they will be immediately passed through the multiplexer and trigger MethodX:
What is Method Overloading?
An overloaded method is one that is triggered by a multiplexed event that contains a number of different event types. When the method fires, it examines the type of the event that triggered it and performs a different function in each case. Methods always have a Process() function that is called regardless of the event type that triggered it, but in the case of overloaded methods, a special process function can be generated based on the event having arrived through particular multiplexer link numbers. For more information on setting up these overloads refer to Creating Overload Mappings.
The following example is the same as the previous example except that the connections have been labelled A, B and C respectively. Assuming overloads have been set up corresponding to each link and given the same name as the link, in this case the translator will generate three entry points Process_A(), Process_B(), and Process_C() which will be executed when StoreA, StoreB and StoreC are 'ready-to-read' respectively.
Example
The following example shows a multiplexer that is implicitly 'irregular' and the Processing method will therefore require two user entry points to deal with the two cases. This is actually a fairly common construct; the execution of the processing code depends on some control data. The method needs to execute when it has collected both input and output (triggering the Proc connection); but also if control changes (triggering the Ctrl connection).
Typically, the control data will be stored in the Processing method's state and this local copy will be updated each time control is updated. The Processing method can then use its state copy rather than continually opening the Control store for read. It is this need to share state between the two entry points that means that the two events are multiplexed. Exactly the same functionality could have been achieved by having two methods share the control store.
